EMULATION TECHNIGUES ON THE RCA SPECTRA SYSTEMS 


The very rapid advances in computer technology have made it desirable for users 
to update their existing data processing equipment with third-generation hard- 
ware. To accomplish this transition, a user must consider the cost of converting 
his programs—a major project for which the typical user seldom has a sufficient 
programming staff. In the past, simulation software has been supplied by the 
manufacturers to facilitate the program conversion effort; however, this tech- 
nique is very inefficient. Simulation in general is economically practical only for 
infrequently run programs, and the more frequently run programs must immedi- 
ately be recoded before the old system can be replaced. Emulation is a tech- 
nique involving both hardware and software which permits existing programs 
written for the old system to be efficiently run directly on the new system. The 
hardware cost is small and the performance is at least an order of magnitude 
better than simulation. 
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OMPUTER TECHNOLOGY has continued 
C to experience rapid advances in 
machine performance, range of applica- 
tion, and varieties of peripheral devices. 
Accordingly, data processing users have, 
at various times, had to consider the eco- 
nomics of trading in outmoded equip- 
ment and replacing with the latest units. 
As users have become more sophisticated 
in the application of computers, a sub- 
stantial investment exists in their library 
of programs and data files. The con- 
siderations of how to make a smooth 
transition from one system to another 
with minimum loss of investment has 
typically been traumatic. 

There are currently several techniques 
that aid in this conversion, but none is a 
panacea: 

Higher Level Languages: Any portion of 

the work that has been programmed in a 

machine-independent language can be run 

on a new computer, if a compiler is pro- 
vided for that language. However, com- 
pilers have not been truly machine inde- 
pendent and often the language compilers 
are not available with delivery of the 
equipment. Further difficulties arise when 
machine language coded subroutines are 
mixed with the higher level language 


statements to patch in a special feature 
or fix a bug. 

Translation: Each instruction or group of 
instructions can be automatically changed 
from the machine language of the old 
computer to that of the new. This transla- 
tion is performed from either source 

Final manuscript received May 2, 1967. 


a 


language or object program decks. 
Translators process the instructions be- 
fore execution time; hence, it is difficult 
to translate an instruction that will be 
modified or replaced by the program it- 
self before its actual execution. Transla- 
tion is generally less successful between 
two computers that differ widely in 
architecture. 

Simulation: Simulation differs from trans- 
lation in that each instruction is inter- 
preted in sequence at execution time. An 
image of the entire state of the computer 
being simulated (memory contents, reg- 
isters, indicators, etc.) is maintained on 
a bit-for-bit or character-for-character 
basis in the simulating computer. Strict 
adherence to this rule of interpretation 
at execution time removes the conceptual 
problems present with translation. Be- 
cause of their simplicity, interpretive rou- 
tine simulators have been quite successful. 
Unlike a translator, a simulator must in- 
terpret an instruction each time it is exe- 
cuted rather than just once. Thus, there 
is a large performance degradation due 
to the interpretive overhead. Further limi- 
tations are often required on the fidelity 
of the interpretive routines to keep the 
simulation program size within reason. 
Most simulator programs have not been 
fast enough to be of significant value in 
the conversion efforts. 

Reprogram: As a last resort, a problem 
may be reprogrammed in the new com- 
puter language. This reprogramming is 
costly, time consuming, and is just a 
brute force solution to the conversion 
problem. Eventually, all programs of 
value will be reprogrammed. However, 
reprogramming and debugging to this 
extent during a tolerably short transition 
interval is usually not feasible. 
Emulation: An emulator is a package 
supplied by the computer manufacturer 
that includes special hardware and a 
complementary set of software. The pack- 
age runs in the manner of an interpretive 
routine simulator program but is approxi- 
mately an order of magnitude faster. The 
combination of emulator and the new 
computer in effect create an extended 
computer which, to the user, is the com- 
puter for which the original object code 
was written. The advantages of emula- 
tion are simplicity of operation and system 
thruput performance. Thruput can typi- 
cally range from equal to four times 
better than the original system depend- 
ing on the application. 


EMULATION 


In the Spectra computer series, emula- 
tion is used to perform the interpretive 
processing on all non input/output in- 
structions by hardware microprogram. 
Interpretive processing of input/output 
instructions is handled by the comple- 
mentary set of software. Microprogram 
computers generally have two sequence 
counters, one for the macro-instruction 
sequence, with which the machine lan- 
guage programmer is familiar, and one 
for a micro-instruction sequence, which 
interprets and executes the macro-in- 
struction. These micro-instruction se- 
quence steps are called elementary 
operations (£0’s) and are pre-wired in a 
read-only memory. 

The economic feasibility of read-only 


memories has allowed the Spectra 70/35 
and 70/45 computers to employ these 
techniques for system control. Addi- 
tional read-only memories may be op- 
tional add-ons to the system; each one 
containing the micro-instruction steps 
corresponding to a particular order code. 
Several earlier machines of the micro- 
program type have been described in the 
literature and include the TRW-133’, 
Packard Bell 440° and Collins 8401°. The 
Spectra 70/45 and 70/35 have also been 
described.*” 

A microprogram simulation is invari- 
ably more efficient than a macroprogram 
simulation, since the interpretation is 
being executed at a point of least differ- 
ence between the computers. On a 
macroprogram level, computers have 
widely different structures: instruction 
formats, fixed or variable data fields, 
binary or decimal character codes, etc. 
On a microprogram level, the ability to 
process bit-by-bit or character-for-char- 
acter allows the more complex macro- 
level operations to be implemented by 
relatively straightforward sequences of 
elementary-bit or character manipula- 
tions. 

To take a different view of the effi- 
ciency of micro versus macroprogram- 
ming, a given data processing problem 
coded in machine language for several 
computers causes a wide variation in the 
total number of memory cycles. The 
most efficient routine is a result of the 
computer with the best instruction reper- 
toire for the original problem. This has 
been evident in the performance of soft- 
ware simulators. Emulators or micro- 
programmed simulators allow routines 
which, in terms of memory cycles, show 
little difference from the original com- 
puter’s operation. Interpretive routine 
simulation by hardware microprogram 
allows the process to be done at the point 
of minimum difference. 

The complementary set of software in 
emulation has a large part to play. In 
several cases, it becomes uneconomical 
to do a function by microprogram. Soft- 
ware control of input/output sequences 
allows a flexible approach to perform- 
ance enhancements such as buffering, 
look-ahead, multiprogramming, and ad- 
ditions of facilities for handling periph- 
eral devices not included in the initial 
microprogram release. Execution of ap- 
propriate error-recovery procedures is a 
problem best handled by software. Also, 
to the operator, the systems are totally 
dissimilar; the software provides an in- 
terpretive console to allow execution of 
operating procedures in the most con- 
venient manner. 


IMPLEMENTATION 


Emulation is provided on the 70/35 and 
70/45 by the inclusion of additional 


read-only memory banks, special soft- 
ware package, and some minor hardware 
modifications to the respective proces- 
sors. The added read-only memory is 
used in two ways: interpret the instruc- 
tion repertoire of the machine being 
emulated and to provide some special 
Spectra 70 instructions to assist the soft- 
ware portion of the emulator. The wired 
program within the read-only memory is 
referred to as the Emulator Micropro- 
gram (EMP). 

The software portion of the emulator is 
called the emulator control program 
(EcP) and consists of two components: 
the emulator monitor system (EMSs) and 
the emulator interface program (EIP). 
The Ems is a special operating system 
designed to run any of the Spectra 70 
emulator features. The Erp is a special 
software package designed for each emu- 
lator to interface the emp with the Ems. 
Both the Erp and EMS are programs writ- 
ten in Spectra 70 code. The primary 
responsibilities of the EIP are: 

1) Translate the 1/o instruction of the 
machine being emulated to equivalent 
Spectra 70 operations; 

Perform any peculiar code transla- 
tions; 

Interpret 1/0 termination conditions 
and set any necessary emulated indi- 
cators; and 

4) Interpret and execute all emulated 

console functions relating to errors, 

normal operation intervention, initiali- 

zation, ete. 
The hardware modifications consist of 
the control logic necessary for selecting 
and addressing the added read-only 
memory banks, and some added func- 
tions, to the microprogrammed structure 
of the machine to facilitate or enhance 
the emulation capability. In the imple- 
mentation discussion which follows, it is 
assumed that the reader is generally 
familiar with normal Spectra operations 
and technology.”® 

The operation of the emulator is con- 
trolled by two control bits in the Inter- 
rupt-Status Register. The first bit is the 
Emulator ON (EON) and the second bit 
is the Bank 3 (BK3) control; the BK3 
control selects one of two possible emu- 
lators. The 70/45 allows up to two dif- 
ferent emulators to be added to the sys- 
tem; the 70/35 allows only one. With 
the Emulator ON (EON-1) the four nor- 
mal program states of the Spectra 70 
processor take on the following func- 
tions: 
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Program State ] fetches and executes all 
instructions out of the added read-only 
memory (bank 2 or 3 depending on the 
state of the BK3 emulator control). 
Program States 2, 3 and 4 fetch and exe- 
cute all Spectra instructions out of the 
original Spectra read-only memory bank 
and allow a special set of EIP instructions 
unique to the emulator. 


By designing the program states to 
operate in this manner, the emulator can 
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incorporate normal Spectra 70 coding 
for the EcP which must be executed in 
program states 2 and 3 and execution of 
the user’s program being emulated in 
program state 1. 

Fig. 1 illustrates how the program 
states of the Spectra 70 are used by the 
emulator. Program state 1 is the state in 
which the user program is executed un- 
der control of the emulator micropro- 
gram (EMP). State 3 is used by the EMs 
to analyze all program interrupts. All 
interrupts, once analyzed, are turned 
over to either the emulator monitor sys- 
tem (gMs) or emulator interface pro- 
gram (EIP) in program state 2 for proper 
handling of the interrupt. In program 
state 2, the bulk of the rrp and EMs are 
executed. An EIp routine analyzes all 1/o 
instructions encountered by the EMP and 
prepares them for execution. Program 
errors encountered in the user’s program 
are handled in program state 2; the con- 
sole routine for operator communications 
is contained in program state 2 and the 
1/o control program which is responsible 
for issuing all 1/0 commands are also 
contained in program state 2. 

During execution of a user program, 
the Emp will turn control over to the EcP 
for any of the following reasons: 


1) An 1/o instruction is staticized and 
decoded; 

2) A condition is detected that would 
result in a machine halt or malfunc- 
tion in the emulated machine; or 

3) The instruction fetch or data fetch/ 
store was outside permitted memory 
bounds. 


For the first two conditions, the emp will 
turn control over to the EIp in program 
state 2 directly. Communication with 
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the Erp portion of the emulator is through 
a communication constant which is used 
by the software to determine the reason 
for the Erp call. In the case of an 1/o in- 
struction, the E1p will return control back 
to the EMP in program state 1] as soon as 
the 1/o instruction has been executed 
and/or the device started. In the case 
of error conditions, the EcP will gen- 
erally be required to give a printout on 
the console and wait for a response by 
the operator. Under any condition, the 
ECP will return control to the EMP in pro- 
gram state 1 only when the emulated 
program is able to continue its opera- 
tion. The third condition is an automatic 
interrupt to program state 3 where it is 
handled like all other interrupts by the 
EcP. Special hardware has been added 
to the processor to facilitate the detec- 
tion of the memory boundary used by the 
emulated program. This is a special 
addressing error condition detected only 
when the emulator operation is in effect. 


MAPPING 


The operation of the emulator depends 
on an instruction-for-instruction inter- 
pretation of the: program being emu- 
lated. To do this, the characteristics of 
the native machine must be mapped one- 
for-one into the Spectra processor. To 
date, all of the machines being emulated 
on the Spectra equipment have been 
character oriented and, with the excep- 
tion of the RCA 501, are decimally ad- 
dressed machines. Spectra is a combi- 
nation word and character machine with 
binary addressing and 8-bit characters. 
These characters of the Spectra and the 
machines to be emulated permitted a 


rather straightforward mapping of mem- 
ory on a character-for-character basis. A 
contiguous portion of the Spectra main 
memory represents the main memory of 
the system being emulated. This portion 
of the Spectra memory is bounded on 
both sides by a special character which 
is used by the emp to detect an operation 
which crosses the boundary. The ecp or 
software portion of the emulator resides 
outside these boundaries. To permit 
multiprogramming and facilitate two 
emulators in the system, the mapped 
memory is floated. - 

In addition to main memory, all regis- 
ters and indicators used or referenced 
by the instruction repertoire of the native 
machine must be mapped or allocated 
equivalent storage in the Spectra 70 sys- 
tem. In all the emulators designed to 
date, the Spectra floating-point registers 
were assigned the function of represent- 
ing the native machine registers and in- 
dicators. These were chosen for two 
primary reasons: 

1) The floating point registers were not 
needed by the software portion of the 
emulator, and therefore, would not re- 
quire storing and restoration every 
time the program state is changed; 

2) The software system operating in pro- 
gram states 2 and 3 can access the 
floating-point registers as readily as the 
Emp. This later was a key considera- 
tion since both the software and, par- 
ticularly, microprograms require fre- 
quent access to the mapped registers. 

The ready availability of these regis- 
ters is a major factor in the performance 
of the emulator. 

In addition to the mapping of registers 
and memory, the emulator requires stor- 
age for conversion and translation tables. 
Address conversion and code translation 
tables are required to enhance the per- 
formance of the emulator. In all the 
Spectra emulators to date, the general 
registers for program state 1 were allo- 
cated to address conversion tables, since 
these registers are most readily accessi- 
ble by the emp, and address constants are 
the most frequently accessed arguments. 
Other tables needed by the micropro- 
gram utilize a special portion of main 
memory which is not accessible to the 
programmer. Normally, this portion is 
allocated to the multiplexer subchannel 
register. This restricted the number of 
subchannel registers that the emulator 
system could use to 64. However, this 
has not affected any system configura- 
tions to date since 64 still provides ade- 
quate room for expansion. This approach 
has the advantage that more of the main 
memory space is conserved for the pro- 
grammer. 


EMULATOR MICROPROGRAM 


The emulator microprogram (EMP) con- 
sists of the following parts: 
1) Instruction fetch and decode; 


2) Individual execution algorithms for 
emulated instructions; and 

3) Decode and execution of all special 
Spectra instructions, 


The instruction fetch and decode por- 
tion of the emulator microprogram is en- 
tered automatically whenever an instruc- 
tion in program state 1 is completed or 
whenever control is returned to program 
state 1. This portion of the Emp is com- 
mon to the interpretation or execution of 
all emulated instructions. It fetches 
from mapped memory the next instruc- 
tion, performs any necessary address 
conversions, updates all simulated ma- 
chine registers, decodes the operations, 
and enters the execute portion of the 
instruction. 

The instructions consist of individual 
microprogram routines. In the case of 
non-1/o instructions, these routines per- 
form the operation and leave all simu- 
lated registers, indicators, and memory 
locations exactly as in the native ma- 
chine. In the case of an 1/o instruction, 
the Emp decodes the particular operation 
into an ECP communication constant 
which is utilized to select an appropriate 
EIP subroutine. Control is then switched 
by the Emp to program state 2 so that this 
selected 1p subroutine may proceed with 
the translation into an equivalent Spectra 
operation. The erp will return control to 
the Emp only after the 1/o operation is 
completed or the device is initiated and 
1/o simultaneity is specified and_per- 
mitted. 

The third portion of the EMP consists 
of the microprogramming routines for 
special operations to assist the EIp. For 
example the 301 emulator uses a move 
and translate instruction to move data of 
specified length from one memory loca- 
tion to another, translating the codes 
from one representation to another via a 
specified conversion table. In the case 
of this special operation, the EIP can 
translate 1/o data from 301 codes to 
Spectra codes, thus permitting standard 
Spectra devices to be substituted for 301 
devices. The special operations are in 
the format of Spectra 70 instructions and 
can only be executed when in States 2, 3 
or 4 and the EON control is set to one. 
If the emulator is not ON or the emulator 
bank specified is not installed, these 
special operation codes (op-codes) will 
cause a normal illegal op-code error to 
occur. The special op-codes are fetched 
and staticized as a normal Spectra 70 
instruction using the Spectra read-only 
memory bank. In the Spectra 70 stati- 
cizing microgram, a group of unused 
op-codes are assigned to these special 
operations and are designed to auto- 
matically branch to a fixed read-only 
memory location in the emulator bank. 
If the emulator is not installed or the 
emulator control is not ON, this branch 


will result in an op-code error. At this 
fixed read-only memory location, the EMP 
must decode all the special operations 
for this particular emulator. Once de- 
coded, the Emp completes the execution 
of the special operation. This technique 
of expanding the Spectra repertoire per- 
mits each emulator to have its unique set 
of special instructions. 


EMULATOR SYSTEM PERFORMANCE 


In an emulator system design, perfor- 
mance is predominantly determined by 
1) similarity of the processor being 
emulated and the emulating processor 
and 2) degree of fidelity desired in the 
processing functions. These factors can 
be separated into two categories: those 
related to the internal instructions and 
those related to the jnput-output func- 
tions. A partial list of items found to 
be of principal significance is tabulated 
below: 


Internal Instructions 


1) Conversion of decimal memory ad- 
dresses to a binary equivalent; 

2) Differences in character codes be- 
tween the system being emulated and 
Spectra representations. 


Input-Output Functions 


3) Per-character processes required on 
data exchanges with peripheral de- 
vices ; 

4) Emulator software overhead required 

for interpretative translation of input/ 

output requirements; and 

Peripheral equipment speed differ- 

ences. 
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Memory Address Conversion 


All Spectra data processors employ 
straight binary-coded address references. 
The 70/45, for example, allows binary 
addresses ranging to 18 bits. However, 
the 1410 system employs a five-digit deci- 
mal field. The 1401 and 301 systems em- 
ploy six-bit characters with a combina- 
tion of decimal digits and zone bit com- 
binations within each character of the 
address field to designate a memory 
reference. A conversion must thus be 
performed for each operand address 
fetched from the native address format 
to an equivalent Spectra binary refer- 
ence. Since the base of mapped memory 
or equivalent location of the emulated 
systetn’s zero address is relocated to 
some other non-zero value, this offset 
must be incorporated in the address 
conversion algorithm. These conver- 
sions have generally been implemented 
through series of decimal-to-binary table 
lookups so as to reduce the execution 
time. To further reduce the extra addi- 
tion cycle required for the mapped mem- 
ory base offset, one of the decimal-to- 
binary tables is offset an equivalent 
amount by the emulation software at 
initial load time. Thus, the decimal-to- 
binary weight and base offset are avail- 
able in one table lookup operation. 


Character codes 


Character-code representations in the 
system to be emulated and Spectra equiv- 
alents are generally not the same. Oper- 
ations such as comparisons and addition/ 
subtractions therefore follow different 
rules. For example, the six-bit binary- 
coded decimal (Bcd) representations 
used in the 1410 and 1401 systems differ 
from Spectra formats in two ways: 

1) The collating sequence used in com- 
pare operations does not correspond 
to the actual binary weights; and 

2) The binary representation of the deci- 
mal digit zero is 1010, not 0000 as in 
Spectra. 

To eliminate special translations for 
every compare or arithmetic operation, 
the 1400 scp characters are represented 
internally in extended scp interchange 
code (EBcDIC) whose binary codes cor- 
rect the above peculiarities. Since 
EBCDIC is a standard for Spectra equip- 
ment, compatible translation facilities 
are included in all input/output devices 
to convert card, tape, etc. codes into 
EBCDIC as the data is entering or leaving 
the processor. Thus, the codes are auto- 
matically translated as data is read or 
written and internal emulator processing 
of the characters is compatible with the 
Spectra hardware arithmetic unit. 

Some internal operations still require 
conversion of the EBcDIC codes into BCD, 
and vice versa. Examples are the move- 
digit/zone or branch-on-bit-equal in- 
structions. However, the additional pen- 
alty to these instructions is smail 
compared to the gains in other algo- 
rithms. 

Similar problems, although not as 
severe, occur with 301 and 501 codes. 
Here the difficulty is concatenation of a 
six-bit character into an eight-bit byte. 
Special provisions must be made to in- 
sure proper propagation of carries in 
arithmetic operations. 


Per-Character I/O Processes 


Input/output operations in the Spectra 
system are count controlled. For in- 
stance, a tape write command employs a 
starting memory address and a specific 
number of bytes to be written out. Input/ 
output instructions available in the 1410, 
1401, and 501 systems, however, are sym- 
bol controlled. That is, the length of a 
field to be written out (or read in) is 
determined by the location of a special 
terminating symbol in memory. Thus, 
before an emulated 1/o instruction can 
be converted into an equivalent Spectra 
command, the field must be scanned to 
determine a byte count. This scanning 
operation adds to the time required to 
execute an I/O instruction and consti- 
tutes additional overhead. The time in- 
volved is determined on a per-character 
basis and if performed with conventional 
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instructions, would range from approxi- 
mately 10 to 25 us, depending on appli- 
cation. However, by utilizing special 
microprogrammed routines designed for 
these processes, the per-character times 
range from 1.2 to 5.5 ws. Through micro- 
programming techniques, almost an or- 
der of magnitude improvement was pos- 
sible. When compared with the data rate 
from a 60KB tape station, this processing 
typically represents an increase of only 
15% in data transfer time, which is ex- 
clusive of start/stop delays. Thus, the 
apparent increase in total type time is 
not excessive. 


Emulation Software Overhead 
The complimentary software package 
employed in an emulator (called EcP) 
provides the translation linkage to exe- 
cute 1/0 instructions. To perform this 
function, a variety of actions are re- 
quired 1) to initiate the equivalent Spec- 
tra device operation and 2) to translate 
termination conditions into correspond- 
ing mapped emulation indicators. Where 
appropriate, routines have been included 
to enhance system performance. These 
include such facilities as: 
1) Advanced card reading into a buffer 
area; 
2) Advanced print release by moving data 
to be printed into a buffer area; 
3) Error recovery through retries; and 
4) Provision for multiprogramming two 
emulation operations. 
Typically, execution of the ECP rou- 
tines adds 0.5 to 1.5 ms to the execution 
time of an 1/o operation (exclusive of 
any per-character processing). This 
overhead can be minimized by overlap- 
ping the processing with input/output 
operations and using the above enhance- 
ments. 


Peripheral Speed Differences 

Device speeds in 1/0-bound programs 
have as direct a bearing on overall thru- 
put as execution time of internal instruc- 
tions in compute-bound programs. By 
selecting peripheral devices which are 
faster than the corresponding units in 
the system being emulated, substan- 
tial improvements in thruput can be 
achieved. The start/stop characteristics 
of 1/o devices can be as significant in 
system performance as the data rates; 
particularly where short records are in- 
volved. It is difficult to predict 1/o per- 
formance or system thruput due to the 
complex inter-relationship between the 
device time, EcP overhead, and internal 
instruction mix being executed through 
microprograms. 


Performance Measurements 

The level of emulator performance is 
usually measured by total program thru- 
put, This performance is determined 
by inter-relationships between the fol- 
lowing: 


1) Execution time of the micropro- 
grammed internal (non-I/0) instruc- 
tions; 

2) 1/0 device character rates and start/ 
stop times; 

3) recp overhead time required to translate 

1/0 requirements into Spectra equiva- 

lents; and 

The timing distribution of the above 

three items in actual operations. 
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The “average” performance ratios of 
native instruction times to emulated in- 
struction times are listed below: 


Parameter 1410 1401 801 50L 
Memory Speed Native 
System (4s) 4.5 11.5 7.0 15.0 


Performance Ratios: 

Native time of 70/45 2.3 4.1 2.6 2.4 

Native time of 70/35 * 3.8 1.6 * 
* 1410 and 501 emulators are not available for the 

70/35 system. 

These figures were derived from a 
weighted mix of typical internal instruc- 
tions, and hence are considered “aver- 
age.” The ratios vary from 1.6 to 4.1 and 
in no case is emulation slower than the 
original system; these figures illustrate 
the efficiency of emulation at the micro- 
programmed level versus simulation at 
the instruction level. Typical perfor- 
mance of simulation programs would be 
approximately an order of magnitude 
slower. 

If programs only consisted of internal 
instructions and essentially no 1/0 ac- 
tivity, then the above ratios would 
properly represent thruput. However, 
most commercial data processing activi- 
ties are quite dependent on extensive 1/0 
activity. Thus, performance of the peri- 
pheral devices is a very significant factor 
in determining thruput. Peripheral de- 
vice performance between the native sys- 
tem and emulating system may generally 
be compared on two accounts: per- 
character data rates and start/stop times. 
Since 1/0 activity can be (and usually is) 
overlapped with internal processing func- 
tions, an emulating system with devices 
twice as fast as the native configuration 
and a minimum of non-overlapped pro- 
cessing will not have an equivalent in- 
crease in thruput. 

Any rcp overhead time required to 
translate 1/0 requirements into Spectra 
equivalents adds to the execution times 
of the 1/o instructions. EcP device initia- 
tién/ termination sequences are by their 
very nature non-overlapped with any 
emulation processing time. Device initia- 
tion or termination times may only be 
overlapped with 1/o activity on another 
1/o channel if such activity is required 
by the program being emulated. To this 
extent, ECP overhead does not quite add 
directly to total program execution time. 
However, the effects of rcp overhead are 
most noticeable in 1/o bound programs 
handling short records. Per-character 
1/0 processing is an ECP function and 
since it occurs at initiation or termina- 


tion time, can be considered as an ex- 
tension of the EcPp overhead factors. 

The most complex factor affecting 
performance is the timing distribution 
of internal processing, 1/0 activity, and 
EcP overhead functions. These inter- 
relationships can cause idle processor or 
1/o time at points in the emulated pro- 
gram where none existed in the native 
system. Evaluation of this factor in the 
design of emulators was only attempted 
through timing simulation runs. The 
effects and interrelationships were too 
complex to predict by a simple set of 
ground rules. Actual program running 
times have been measured on the 301 
and 1410 emulators for the 70/45. The 
thruput ratios range from 1.30 to 2.95 
on the 301 and from 1.89 to 2.66 on the 
1410. The variability of thruput reflects 
the interplay between the four perfor- 
mance factors described above. 


CONCLUSIONS 

The emulators, as described in the article, 
are currently operational. Field experi- 
ence has proven them to be a valuable 
program conversion technique. It has 
been demonstrated that a user program 
can be run directly on the emulator with- 
out reprogramming and with an actual 
increase in performance. Emulation has 
been made economically feasible, pri- 
marily because of the use of read-only 
memory in the design of the computer 
control and the improved cost-perfor- 
mance ratio of third generation hard- 
ware. 

Emulation, on the other hand, has not 
solved the reprogramming problem faced 
by a user who wants to take full ad- 
vantage of third generation hardware. It 
does, however, permit him to spread his 
reprogramming investment over a longer 
period of time. Although the primary 
purpose of emulation is to ease the user’s 
burden of reprogramming, it has, in cer- 
tain instances, actually reduced the total 
rental cost. 
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